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ABSTRACT 


The DoD is burdened by an Integrated Defense Acquisition, Technology, and Logistics 
Life Cycle Management System that is designed to acquire large systems, such as ships, 
and that takes years to complete. Information technology evolves at a rapid pace because 
it is driven by industry. The DoD acquisition system is therefore at odds with industry 
development, at least with respect to information technology. Acquisition of information 
technology cannot follow the same path as a ship if the DoD wants the warfighter to have 


the most advanced technologies. 


The acquisition of technology is about much more than the technology alone. 
Each stage of the acquisition process, even for technologies that are never ultimately 
adopted, offers some information that needs to be cataloged in a way that others can use 
it. This thesis proposes a clearinghouse for this purpose. The clearinghouse should 
decrease the amount of time required to get information technology to the warfighter. 
The changes that need to occur are not limited to information sharing. Although that is a 


central component, this thesis identifies other barriers that must be overcome. 
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I. INTRODUCTION 


A. KEEPING PACE WITH INFORMATION TECHNOLOGY WITHIN THE 

DOD 

It is recognized by the DoD, the Defense Science Board, Congress, the 
Government Accounting Office, and, most importantly, by the warfighters themselves 
that the current Integrated Defense Acquisition, Technology, and Logistics Life Cycle 
Management System needs overhauling, specifically for acquiring rapidly evolving 
information technology systems (Defense Science Board [DSB], 2009; Government 
Accountability Office [GAO], 2008, 2009a, 2009b, 2010). Acquisition in the DoD spans 
a wide range of technologies and readiness levels, called technology readiness levels 
(TRLs). For a deeper understanding of TRLs, see Appendix A. Among the highest 
readiness levels are weapons systems, communications, and information technology (IT). 
Some technologies are developed specifically for military use and others are commercial 
technologies adapted for military use. Communications and IT are two areas that borrow 
extensively from the commercial world. With private funding behind them, they tend to 
evolve rapidly, presenting a serious challenge to DoD acquisition. While adversaries can 
adopt these technologies quickly through online resources and web stores, the DoD has to 
follow a process that, in many ways, is the same process used for acquiring large-scale 
systems. As Deputy Defense Secretary William J. Lynn III pointed out, the process has 
not been efficient: 

The U.S. military is the most capable armed force in the world, in part, 

because of the edge given by the reliance on information technology, but 

the procurement process for software and hardware still is mired in the 

industrial age, tied to the way the department buys tanks or ships or 

aircraft. In this very ordered process, we decide what the mission is, 

identify the requirements that are needed to meet that mission and analyze 


alternatives to meet those requirements, eight or nine years later, we 
actually have something. (Garamone, 2010) 


Currently, the DoD acquires technology through the Integrated Defense 
Acquisition, Technology, and Logistics Life Cycle Management System. This system is 
overwhelming in bureaucracy, in time, and in complexity. Appendix B contains a current 
pictorial roadmap of the entire Integrated Defense Acquisition, Technology, and 


Logistics Life Cycle Management System. Figure 1 shows an overview of this process. 


Engineering and 
Manufacturing Development Deployment 


Post POR Post COR 
Asseiaent - papesamane 





Figure 1. Snapshot of Defense Acquisitions Life Cycle Management System (from 
Murphy, 2010) 


The Integrated Defense Acquisition, Technology, and Logistics Life Cycle 
Management System is comprised of three key processes that must work together to 


deliver products to the warfighter: 


° The requirements process (Joint Capabilities Integration & Development 
System, JCIDS), 

e The acquisition process (Defense Acquisition System), and 

e The program and budget development process (Planning, Programming, 


Budgeting, and Execution, PPBE). 
Each of these processes is governed by policies from multiple DoD documents. 
Furthermore, under DoD Instruction 5000.02, the acquisition process is broken up into 
phases that are divided by major decision points called milestones. In Figure 1, the 


milestones are represented by triangles with letters inside. Because each acquisition is 
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unique, the acquisition system allows DoD acquisition professionals to tailor the number 
of phases and decision points inherent in each program. The individual tailoring 


available is graphically shown in Appendix B. 


To further complicate IT acquisition, organizations within the federal government 
have inserted many other hurdles into the process through either policy or law. One 
example is the Department of Defense Information Assurance Certification and 
Accreditation Process (DIACAP), a required process for all IT acquisitions. The process 
is complex and time-consuming in order to achieve and maintain the required authority to 
operate (ATO) a network. The DIACAP process requires interaction with National 
Institute of Standards and Technology (NIST) guidelines. The NIST is an agency 
responsible for developing information security guidelines under the Federal Information 
Security Management Act (FISMA); these guidelines can be accessed on the NIST’s 
website (http://csrc.nist.gov). Two NIST special publications were released in May 2010 
in order to provide more clarity and to streamline the Information Assurance Certification 
and Accreditation ([A C&A) process by including the following documents: (1) 
Recommended Security Controls for Federal Information Systems and Organizations, 
which provides a common risk management strategy for federal security (National 
Institute of Standards and Technology [NIST], 2009); and (2) Guide for Assessing the 
Security Controls in Federal Information Systems and Organizations, which provides 
updated assessment techniques and procedures (NIST, 2010). These documents are 
considered positive steps forward because they are current and reflect known issues and 
time concerns faced by DoD acquisition professionals during the [A C&A process. The 
documents also provide standards on which the industry can build their products and that 
will then speed up the IA C&A process. Despite attempts such as these to streamline the 


DIACAP process, it remains woefully cumbersome. 


The National Defense Authorization Act (NDAA) for Fiscal Year 2004 (2003) is 
aimed at overcoming these burdens when the need is life-threatening and urgent (e.g., 


reinforcing the armor on all-terrain vehicles). IT acquisition normally does not qualify 


for urgent classification; instead, it is governed by the rules and regulations outlined in 
the Integrated Defense Acquisition, Technology, and Logistics Life Cycle Management 


System. 


For commercial information technology that evolves quickly, a more nimble and 
efficient acquisition process is needed. This technology will be referred to in this thesis 
as “Rapidly Evolving Information Technology” (REIT). REIT is commercial technology 
that evolves quickly and is typically information technology with a readiness level of six 
or greater. It demands a more nimble and efficient acquisition process. The DoD is no 
longer the single driving force behind advanced technology acquisition and development. 
Consumer demand is largely driving the evolution of REIT. The DoD’s acquisition 
strategy for such technology is not well suited for this shift to consumer demand driving 
acquisition and needs to evolve. However, the process needs to evolve much more 


rapidly than it has in the past. 


1. A Call to Arms 


IT acquisition reform within the DoD and federal government is an ongoing 
effort. For decades, laws and policies have been changed by both the federal government 
and the DoD. The DoD has attempted to improve its Integrated Defense Acquisition, 
Technology, and Logistics Life Cycle Management System. The Packard Commission of 
1986, the Clinger—Cohen Act of 1996, the National Defense Authorization Acts, and the 
Defense Science Board reports are just a few examples of major attempts to improve the 
system (Christensen, Searle, & Vickery, 1999; DSB, 2009; NDAA for Fiscal Year 1996, 
1996; Ronald W. Reagan NDAA for Fiscal Year 2005, 2004). Problems with cost, 
schedule, and performance recur each decade as the DoD’s needs continue to exceed its 
resources and abilities. The federal government continues to make noble efforts to 
improve the process of the overall system, but improving the acquisition of REIT needs 
additional effort. There is no single, efficient, and rapid solution for acquiring every 
software application or new piece of network hardware. In many cases, REIT advances 
faster than new laws and policies can be put in place to acquire it. In addition to policy, 


people and technology are important to help speed up the Integrated Defense Acquisition, 
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Technology, and Logistics Life Cycle Management System. Rarely do improvements to 
just one process, policy, person, or technology revise the overall situation. A holistic 


approach is needed. 


On October 28, 2009, the NDAA for Fiscal Year 2010 directed the Secretary of 
Defense to develop and implement a new acquisition process for IT systems. The law 
also directed the new acquisition process to include the findings of the March 2009 report 
authored by the Defense Science Board Task Force and titled DoD Policies and 
Procedures for the Acquisition of Information Technology (NDAA, 2009). In February 
2010, the Secretary of Defense signed the DoD Quadrennial Defense Review (QDR), 
which clearly articulated the DoD adherence to the NDAA for Fiscal Year 2010 under the 
Reforming How We Do Business section. Specifically, the QDR discusses broad topics, 
such as reforming how we buy, institutionalizing the rapid acquisition capability, and 
strengthening the industrial base. In addition to the QDR, the NDAA for fiscal year 2010 
established Task Force 804 to provide feedback to Congress within 270 days (Lenat & 
Rode, n.d.). 


2. ‘““Going Embedded” During Research 


To gain a new perspective on the problem, I embedded inside an assortment of 
system commands over a period of twelve months. Among others, these commands 
included MARCORSYSCOM. Each of the commands provided me with a view of how 
information technology is acquired on the front lines. Each command had improved the 
acquisition process in some manner, yet those improvements were not normally practiced 
by the other commands. Collectively, their processes began to shape a new process that 
adapted to a rapidly changing information technology landscape. What emerged was a 
process that has been dubbed “Collective Acquisition.” This Collective Acquisition 
process is characterized by an openness of the commands to leverage their efforts when it 
comes to acquisition. For instance, if a command understands where the potential 
cryptographic weaknesses are in getting a product such as a personal digital assistant 
from one vendor certified by the NSA (National Security Agency) for classified use, then 


this could be shared with another command and perhaps reduce the time to certify a 
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different product from the same vendor. However, there are many obstacles in the way 
of making Collective Acquisition a reality. Some are technical, but others are cultural. 


Each of these obstacles is discussed in Chapter IV. 


3. Thesis Outline 


The remainder of this thesis outlines a framework for acquiring rapidly evolving 
technology, or for Collective Acquisition. Chapter II contains an overview of the 
framework for Collective Acquisition and provides an example of acquiring information 
technology. The backbone of this framework is a new type of information exchange that 
will be referred to as the Capabilities and Requirements Clearinghouse (CRC). It is 
much more than a data repository and is described in detail in Chapter III. Chapter IV 
looks at barriers to adopting the new framework. Finally, Chapter V addresses its 


execution—steps that could be taken to put the framework into practice. 


Hl. COLLECTIVE ACQUISITION 


A. A MOTIVATING EXAMPLE 


The term Collective Acquisition was chosen to highlight its collaborative nature, 
which is key to providing the agility necessary to acquire technologies that evolve very 
rapidly. These technologies tend to be information technologies and fall into an 
acquisition category (ACAT) three classification. No longer should stakeholders operate 
in isolation. Over time, their work should be leveraged across the DoD and other 


agencies. 


An example will help to illustrate the framework for acquiring rapidly evolving 
technology. Suppose two vendors, X and Y, have delivered military solutions, perhaps at 
different times. Each has delivered a system comprised of vendor components under 
various contracts and has had systems certified according to the Joint Interoperability 
Test Command (JITC) standards. These contracts, certifications, costs, etc., are artifacts 
of an acquisition that can be reused. Therefore, Collective Acquisition comprises an 
information clearinghouse called Capabilities and Requirements Clearinghouse (CRC). 
The CRC is populated with information about X’s and Y’s previous deliverables. This is 


the capabilities part of the clearinghouse. 


Suppose a military ground unit wants to deploy a new technology to the field for 
biometrically binding users to cellular phones through speaker recognition, making it so 
that calls placed to a person reach that person no matter which phone they are using. 
After all, cell phones are low-cost alternatives to Joint Tactical Radio Systems (JTRS). 
Cell phones can be lost or stolen, or their batteries can fail. Tracking phone numbers is 


not feasible. This new technology will be referred to in this thesis as “SPKRCELL.” 


As a user speaks, SPKRCELL recognizes the user’s voice and then associates the 
user’s identity with that phone. If the user speaks into another phone, then he or she will 


become identified with that phone instead. To call a person, a user only needs to refer to 


the person by name because the person’s name is mapped to a phone number by 


SPKRCELL using a name resolution function like the Domain Name System. 


Within the Collective Acquisition framework, the need for SPKRCELL is 
communicated initially as is done today through identifying a capability gap, such as 
through an Operational Deficiency Report (ODR). The ground unit would complete a 
standard, one-page ODR. Appendix A contains a copy of the ODR used today. The 
following is an overview of the information required in the report: 

e The operational requirement (who, what, where, when, why, how), 

e The capability required, 

e The operational deficiency, and 

e The solution to be employed. 

The form begins and is maintained as a digital document, which is submitted 
online or through e-mail to the requirements branch of the ground unit’s parent 
command. These reports, though governed by the JCIDS process at a high level, may be 
processed or handled differently at lower levels. For instance, they may be disseminated 
by e-mail in some cases (pushed to users) or uploaded to a website in others (pulled by 
users). Collective Acquisition proposes to standardize how they are handled by storing 
them in the CRC, affording uniform access to them across the DoD. The CRC acts as a 
single access point to combine information, people, and processes from the entire 
command. From the CRC, all future stakeholders in the process have the ability to add 
and edit comments, approve content, and validate the report. The CRC might also offer 
configurable alerts by the requirements branch so that stakeholders can be notified of the 
need for SPKRCELL technology and its timeline via e-mail, voice mail, text messages, 
etc. Within minutes, key stakeholders in the command could be notified of the new 


requirement from the ground unit, leading to faster validation (invalidation) of the report. 


Ultimately, the ODR for the SPKRCELL requirement will be validated or 
invalidated. Either way, there is information that needs to be cataloged. For instance, it is 
extremely important to know whether the SPKRCELL ODR was not validated because a 


stakeholder like the NSA identified a security vulnerability or whether it was not 
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validated by default because the deadline for comment expired. This information is 
stored along with the ODR in the CRC. If a similar requirement emerges in the future, 
then it will be much clearer how to proceed with the history of the SPKRCELL ODR 


available. 


Consider a scenario in which the SPKRCELL ODR is validated and it is not 
urgent (if urgent, a different path needs to be taken). The CRC lifts the ODR’s visibility 
to an approval level. Warfighters and personnel at the requirements, acquisition, and 
budget branches all have access to the SPKRCELL ODR. This access takes place at a 
local command level or higher. It allows enterprise-level planners to see if the 
requirement matches other requirements at higher levels, such as across the entire DoD 


enterprise. 


The CRC has a powerful search feature capable of matching against very 
unstructured data—for example, images and audio recordings. The CRC searches for 
artifacts such as operational deficiency reports and documented capabilities related to 
SPKRCELL ODR. The search may even occur autonomously after the CRC is updated 
with the SPKRCELL ODR. Suppose the search reveals that vendor X once delivered a 
system with a speaker recognition component, and vendor Y delivered a name resolution 
system for personal names. At this stage, an acquisition professional might wish to 
pursue integrating these components to meet the SPKRCELL ODR. This person would 
further query the CRC for integrator options. Some acquisition professionals do not have 
the appropriate expertise, and the integrator options would be information provided by 
the CRC. For the sake of this example, suppose integrator Z appears to be a good 
candidate. The CRC provides contact information for all the parties involved. At this 
point, each would be engaged to explore the feasibility of jointly meeting the ODR within 


suggested budget constraints. 


Suppose X, Y, and Z have come up with a cost estimate that is within budget. 
The Collective Acquisition framework would support budget management through a 
software package like Quicken® (http://www.quicken.com)—in this thesis it will be 


referred to as “QuickenGov.” A budget expert would launch QuickenGov to find funding 
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for X, Y, and Z. QuickenGov would replace complex Excel® spreadsheets and provide a 
better user interface, like those sold commercially for use as personal finance programs. 
It would also provide another very useful feature: QuickenGov would have the ability to 
be programmed to discover opportunities for re-allocation of funding based on success 
and failure criteria and on the overall status of other programs. For instance, if a program 
failed to execute to a specific milestone by a certain time, then DoD leadership and 
acquisition professionals would like to know this fact because it presents a potential 
source of funds. Suppose SPKRCELL hits the Program Objective Memorandum (POM) 
process in an off year and, therefore, does not have funding. In this case, this discovery 
feature would need to be exploited to find funding from another program. Further, 
suppose we discover in these reports three programs of record that are not executing their 
funding in the current quarter and are identified as high risk for failure based on their 
status reports. In order to provide for the new requirement for SPKRCELL in the current 
quarter, the budget expert re-allocates funding from the failing programs into a new 
program for SPKRCELL under integrator Z, who has been contracted to combine vendor 
X’s and Y’s components into a system that meets the SPKRCELL ODR. The Collective 
Acquisition framework provides better visibility into budget and suggests ways it can be 
re-allocated if necessary. Of course, the command in question must have the authority to 


re-allocate funding within the current fiscal year. 


The next step in the Collective Acquisition framework would be to develop and 
execute a test and evaluation plan. The contractual plan would be a combination of input 
from the acquisition professional and integrator Z. The plan would include milestones as 
well as delivery schedules and baseline requirements to meet at each milestone (e.g., Beta 


version). 


The acquisition professional would use his or her experience and knowledge as 
well as the CRC to coordinate what he or she expects to be done during the test and 
evaluation of integrator Z’s implementation of SPKRCELL. The CRC would provide a 
knowledge base for lessons learned and examples of acquisition programs that have been 


completed. The CRC could be queried to discover similar information technology 
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systems in the DoD, which could then be leveraged to avoid starting acquisition programs 
from scratch. Suppose in our example that the acquisition professional conducts a search 
for programs similar to SPKRCELL based on the ODR. The CRC would be populated 
with NIST special publications, as mentioned in Chapter I. As such, the CRC could 
detect special IA C&A testing that needs to be done that perhaps integrator Z did not 
foresee. The acquisition professional would be aided by the CRC because it would be 
working in the background to notify organizations that might have interest in a new 
technology. In the case of the SPKRCELL program, the CRC would alert the NSA after 
SPKRCELL was approved because it contained references to speaker recognition and 
cellular technology. As a result, the NSA would have been given the opportunity to view 
information about the vendors chosen to implement and test SPKRCELL. Therefore, the 
NSA could have proactively contacted the acquisition professional in charge of the 


SPKRCELL program to work with them through the [A C&A process. 


As part of the Collective Acquisition framework for IA C&A and for test and 
evaluation, the acquisition professional would require integrator Z to use a testing system 
available today called the JA test range. The IA test range is a system approved by the 
Designated Approval Authority (DAA) that provides a risk-free environment for 
integrator Z to quickly assess [A compliance and meet the requirements of the acquisition 
professional (mandated by Chairman of the Joint Chiefs of Staff Instruction [CJCS]] 
3170.01 and CJCSI 6212.01) as if they were on the operational network (Chairman of the 
Joint Chiefs of Staff [CJCS], 2008, 2009). The concept of the IA test range replicates an 
operational physical or cellular network using packet generation, virtual machines, and 
other tools to mimic bandwidth constraints and software programs. An important 
extension of the test range is its ability to interface with the CRC in two directions. First, 
results of a test can be entered into the CRC, and, second, test configurations can be 


loaded from the CRC into the IA test range. 


For instance, suppose in our example that the acquisition professional has 
discovered that the NSA is concerned about speaker recognition being vulnerable to man- 


in-the-middle (MITM) attacks. The professional could tailor an MITM threat 
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configuration for the IA test range and load it directly from the CRC into the test range. 


The CRC, in turn, would be updated directly with the results of the test against the MITM 
threat. 


The Collective Acquisition framework comprises powerful search techniques 
found in the CRC. But the framework is not limited to just the CRC. It includes new 
practices such as key interactions between stakeholders at various stages. These 


interactions are as important to acquisition as the CRC itself. 
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HI. CAPABILITIES AND REQUIREMENTS CLEARINGHOUSE 


The CRC is new technology—pieces of which exist in various forms today—and 
is a new system that the DoD should use as a way of significantly improving the 
acquisition of REIT. Some commercial software programs are in use by the DoD that 
help the matching of requirements to capabilities during the acquisition process. IBM’s 
Rational RequisitePro™ is one example of a requirements management tool with the 
ability to trace requirements to capabilities (http://www- 
01.ibm.com/software/awdtools/reqpro/). The CRC will accomplish more than the IBM 
RequisitePro because the CRC will be done through logistics life cycle management and 
through transparent methods of sharing and analyzing information. The system will 
streamline the market research and analysis of alternatives process through better use of 
information, knowledge, people, processes, and technology. The goal of the CRC is to 
accomplish what Bloomberg, E-Trade, and other companies have done in providing in- 
depth information and analysis to financial companies, bankers, traders, and individual 
consumers. The CRC will provide similar information, but its audience will be the 


stakeholders to the acquisition process, including the end user. 


Initial market research and an analysis of alternatives are important steps for 
cutting down the time it takes to process acquisitions through the identification of proper 
material solutions. Products with a TRL of six or greater that are matched to 
requirements significantly decrease the amount of time the acquisition process takes 
compared to low TRLs. The current practices used in market research and in an analysis 
of alternatives involve studies (independently paid for through contractors), online search 
engines, other online resources such as those listed in Appendix D, and individuals who 
have a network of personnel and resources to lean on in order to find information. All of 
these efforts require the person entering the requirement to make an extra effort to find 


what he or she is looking for or to make the determination to buy the technology or to 


13 


develop it. The CRC would decrease the amount of time required for market research 
and for an analysis of alternatives as well as provide better information than what 


normally would be found scattered between a multitude of resources. 


A. HOW DOES IT WORK? 


In order to accomplish these goals, the CRC would need to be a central repository 
or gateway to information used for the collection, dissemination, and transfer of 
information between federal systems and private industry. Interoperability is key to the 
success of the CRC; the more information it can leverage online—by legacy or through 
private industry—the better it will be. The power of the CRC will be in bringing together 
all of the information available and in directing the right information to the acquisition 


professional before it is needed or in demand. 


There are many online resources providing information to the acquisition 
community, but many of these resources do not exchange information (see Appendix D). 
The CRC would act as third-party software capable of pushing and pulling information 
between online resources (see Figure 2) while maintaining the security of the information 
and protecting that information in accordance with laws regarding who can see privileged 
information. The CRC would require all current and future resources to be interoperable 
(provide hooks) through protocol standards that would encourage the sharing of 
information. The information accessible through the online sharing of resources within 
the CRC would make up the backbone of dynamically changing information. To prevent 
duplication, the CRC would have the ability to search, push, and pull information from 
these online resources, but not necessarily to require it to store information on its own 
system (which would duplicate online resources). In order to add legitimacy and to 
ensure the use of the CRC, it will be necessary to incorporate into the system all of the 
legacy information that the DoD has until everything is available online. Within the 
DoD, many efforts have been completed to digitize the large number of documents 
necessary to complete an acquisition. These digitized and searchable documents would 


further add to the information the CRC could leverage. 
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The federal government and the DoD are working to maximize the potential 
offered by software and the Internet in order to improve the Integrated Defense 
Acquisition, Technology, and Logistics Life Cycle Management System. Online 
initiatives required by federal law and DoD policy have populated the Internet with 
multiple online resources related to acquisitions. The CRC would need to utilize the 
existing online resources in order to be a truly dynamic and useful tool in the acquisition 


system. 


Some of the online acquisition initiatives are focused on specific areas of interest, 
such as information assurance. Other initiatives are focused on supplying multiple 
features, such as contractor registration and performance evaluations. The different 
online resources all have one goal in common: to provide better services to the user in 
order to help streamline the acquisition process. However, the online resources overlap 
in some cases and most of the time do not dynamically share their information with each 
other. Furthermore, since there are so many websites, it is difficult for users to remember 
all of the information available and to search each one, creating inefficiency in the 


acquisition process. 


A serious effort should be made to dynamically share the information between the 
online resources and to standardize protocols in order to make the transfer of data 
between them seamless. A consolidation effort should also take place to decrease the 
number of individual online resources; there should be fewer interconnected resources, 
and there should be a third-party system that relates the sites, such as the CRC. The 
dynamic sharing of information across the online resources could be accomplished with 


the CRC acting as a third-party application. 


One approach to consolidating the online resources available is by accessing them 
through a single website. The Integrated Acquisition Environment (IAE) website, 
sponsored by the E-Gov Initiative, states that it “provides one Web site for all things 
acquisition” (https://www.acquisition.gov/index.asp). This website does not include 
everything related to acquisition, but it makes a great effort to advertise online resources 


and tools available to the government and industry. The goal of the website is to simplify 
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and streamline the federal acquisition process for government and industry by providing 
more efficient and transparent practices through links to online resources. It is refreshing 
to see that there is an organization dedicated to improving the online efforts of the 
acquisition community, but more can be done to open up the online resources to each 
other and to leverage collective power. The CRC could act as this force multiplier by 
utilizing these resources collectively (see Figure 2). The IAE is a noble effort to bring 
online links to one website, but it does not provide the relationships between the 
resources that need to exist in order to leverage the resources of the federal government 


and to streamline the acquisition system. 





Figure 2. Sample online resource relational model 


1. Stakeholders 


In order to make the CRC relevant and useful for REIT, it should involve 


important stakeholders within the Integrated Defense Acquisition, Technology, and 
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Logistics Life Cycle Management System. The following is a list of the initial 
stakeholders: 


e Requirements generators (operators); 

e Private industry (Google, Cisco, BAE, small-business owners, etc.); 

e Government research labs and _ institutions (Federal Laboratory 
Consortium); 

e Acquisition professionals; 

e Budget professionals; 


e IA organizations and policy-makers (NSA, NIST); and 


e Interoperability organizations (Defense Technical Information Center, 
DTIC). 


The stakeholders listed are the most important decision-makers, individuals, and 
organizations that would benefit the most from the CRC. Furthermore, they would 
provide the most information and feedback for CRC adaptive learning. This is not an all- 
inclusive list; more should be added by DoD acquisition professionals as needed for CRC 


efficiency. 


2: Incentivize Stakeholders 


The CRC will only be a requirements and information depository, similar to DoD 
Techipedia and the Joint Requirements Oversight Council (JROC) online, unless the DoD 
can incentivize the stakeholders to enter past, present, and future capabilities into the 
CRC. In a memorandum from the Under Secretary of Defense for Acquisition, 
Technology, and Logistics (USD[AT&L]) issued in 2001, the DoD attacked the incentive 
problem facing the acquisition industry. The usefulness of the CRC is defined by its 
ability to access other resources and legacy systems and, in general, to crawl through 
information. The CRC requires a well-defined incentive proposition for all of the 
stakeholders. Entering information could be accomplished in a similar fashion to the way 
information is entered into the classification system used for the capabilities documents 
of the DoD. For instance, most capabilities are associated with products that have 
brochures or product summaries. Using the intelligent system to classify these 


documents would help expedite the input of information into the CRC system. 
17 


Requirements generators would be the easiest group to incentivize because they 
would see returns on their input investment faster than before they used the CRC. It 
would be important to initially track and advertise the time spent from requirement input 
to product-in-hand and to report this information back to requirements generators and the 
chain of command in order to show the importance of the CRC and the value it provides 


Qustification of funding). 


In order to incentivize private industry, different approaches should be used by 
the DoD. Private industry would arguably be incentivized the most through increased 
profits. The CRC would provide industry with access to all requirements generated 
within the DoD. This access would allow industry to market their products to target 
audiences who would likely buy their products. Also, industry would make more money 
through this enterprise approach because organizations and departments within the DoD 
that would normally procure products separately would now all be targeted at a larger 
level because the CRC would connect their similar requirements. Industry could then sell 
more products across the DoD instead of just to small niche markets. Furthermore, smart 
industry analysts with access to requirements could theoretically look for trend 
information and predict where requirements were headed or learn how to build their next 
product. This information would further save industry money by tailoring its research 
towards more relevant ideas instead of riskier ones. Another interesting approach would 
be to monetize the entry of capabilities into the CRC, thereby providing funding to 


industry and research institutions for their work. 


Research institutions and academics would be incentivized to enter information 
about their low-TRL concepts if they were allowed to advertise their ideas to industry and 
the federal government. Private industry leaders or federal government decision-makers 
looking for the next good idea could target a search to find a research lab or academic 
institution that they could fund and then profit from later on. Research institutions and 
academics would benefit because the CRC would be providing them with necessary 
funding for what they are passionate about and for what would advance them in their 


academic careers. Additionally, research institutions and academics are often faced with 
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the challenge of converting ideas and concepts into final products available to end users. 
The CRC would aid in bridging this gap by connecting the researchers with private 


industry. 


Acquisition and budget professionals would be incentivized by the promise of an 
easier process that also provided transparency and fast results. Overall, the benefits could 
be seen across the cost, schedule, and performance metrics tracked by the acquisition 
professionals. Cost could be minimized because there would be a greater likelihood of 
finding programs underway, instead of having to create a new technology or purchasing 
on multiple contracts. The schedule would be shortened because high-TRL products 
could be identified more quickly, and the amount of data available to the professionals 
would shorten the time necessary to make a decision. Lastly, product performance would 
increase based off of feedback entered by different stakeholders into the CRC at different 
points in the acquisition process. The positive and negative feedback would show 
acquisition professionals how the new products were being received and would provide 


information on how well industry was meeting the timelines agreed to. 


IA and interoperability organizations that establish policy and standards for DoD 
acquisitions would be incentivized because of the opportunity to advertise to all 
stakeholders. The more stakeholders build products able to meet current policies and 
standards, the faster the acquisition process will become. Also, pre-C&A products would 
be searched for because they would be identified through the CRC and would take less 


time to get into the hands of the warfighter. 


All stakeholders would be incentivized by a common goal of quickly providing 
warfighters with the latest technologies, which would save lives and allow warfighters to 
accomplish their missions. An additional and more direct approach to adding capabilities 
to the CRC would be for the federal government to require stakeholder input by law, such 
as they require industry to register in the federal contractor database 
(https://www.bpn.gov/ccr/default.aspx) and the Federal Awardee Performance and 
Integrity Information System (FAPIIS; National Defense Authorization Act for Fiscal 
Year 2010, 2009). 
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he Security Risks 


Laws provide boundaries for information sharing. The Federal Acquisition 
Regulation (FAR) and the Defense Federal Acquisition Regulation System (DFARS) 
provide an interpretation of the laws governing federal and DoD acquisitions. The FAR 
and the DFAR would establish the rules for sharing information within the CRC. 
Information already within the CRC and information being entered into the CRC would 
be tagged to identify its origin as well as any caveats associated with the viewing of the 
information. Additionally, classified information would be outside the scope of the CRC 
design presented in this thesis; another CRC for a classified network would be needed 
because of the extra security required. The classified CRC should be designed to search 


below its classification level and to take in all information. 


The current policies and laws for acquisitions are set up to favor the federal 
government as opposed to industry. Agents of the federal government (anyone within the 
DoD) sharing information on the CRC would have the most access to information in the 
CRC. However, the most attention would need to be paid to the sharing of information 
between private industries and the CRC. Competitors would have to be restricted from 
seeing each other’s proprietary work. Private industry would still benefit from insight 


into DoD research, individual requirements, interoperability, and IA information. 


Access by foreign companies to the CRC would be a mitigated security risk. The 
DoD currently contracts with foreign companies as well as with companies based in the 
United States that have global workforces. These companies should not be denied access 
to the CRC. Partnerships exist in industry and academia that leverage foreign technology 
and knowledge. Shutting out these partnerships would also shut out the global 


collaboration between industry and academia. 


Overall, the CRC would control information through permission settings based on 
who was requesting it. The CRC would use redaction for information that was protected 
and would provide contact data if it was necessary for other stakeholders to have access 


to the information. 
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4. [A/Interoperability 


The CRC would have a large impact on the interoperability and IA C&A of 
systems to be acquired. Combining the knowledge of the NIST, the NSA, and the JITC 
would provide stakeholders with a common location for baselines and standards. For 
example, the fastest way to acquire a widget is to acquire one that is already IA certified 
and accredited and JITC approved for interoperability. The CRC would contain all of 
this information, so the customer would be able to easily determine where the products 
were in the process of interoperability and IA C&A. The CRC could leverage efforts 
underway to provide this capability. Among these efforts are the NIST Cross Domain 
Solutions Office, the National Information Exchange Model, the DoD Metadata Registry, 
and the DoD IT Standards Registry. Individual efforts by organizations would benefit 
from the CRC’s sharing of information because these organizations could leverage more 


economies of scale. 


5. Transparency in Contracting 


The CRC would allow transparency for capabilities in the existing contracts. In 
other words, if a search for a capability found an existing contract vehicle in a different 
organization, but still under the DoD umbrella, it would benefit the user. The user could, 
in theory, work out an agreement (Military Interdepartmental Purchase Request funds) to 
use the existing contract vehicle and to satisfy their own requirement in an expeditious 
way because the administrative work would have already been done by someone else. 
DoD Enterprise licensing is a great example of how the entire DoD benefits from sharing 


a single requirement, such as Adobe® Connect’, across all Services (Johnson, n.d.). 


6. Added Benefits 


The Federal Technology Transfer Act of 1986 directed the DoD and Federal 
Laboratories to make a focused effort to transfer federal research ideas to private industry 
for the benefit of the consumer and state and local governments. This law has created 
organizations (e.g., the National Technical Information Service and the Federal 
Laboratory Consortium for Technology Transfer) that are responsible for ensuring federal 
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law is not violated (Federal Technology Transfer Act of 1986). The National Technical 
Information Service functions as a central point for the collection, dissemination, and 
transfer of information on federal technologies and would be part of the CRC network 
(Department of Commerce, n.d.). The CRC would be a useful tool for these 
organizations because it would be proactive and would bridge private industry and the 
federal system. The CRC would reduce the time and cost to transfer technologies from 
the government to the public through the advertisement of government technologies to 
industry. The main reason for the reduction in time and cost would be because the 
database of research ongoing under the DoD would be updated to industry without the 
researchers having to put forth much effort. Therefore, time and cost would be reduced 
because industry would have direct insight as to what the government is focusing on and, 


therefore, likely to buy at a future time. 


The CRC would provide the ability to leverage more of the scientists and 
researchers in the Federal Laboratory Consortium (http://www.federallabs.org). The 
system could couple researchers who are working on similar projects in order to 
encourage collaboration across physical boundaries. The CRC would allow the DoD to 
utilize the federal government’s existing investment in research and development through 
access to their ongoing information. Also, the CRC would be beneficial to the DoD and 
the federal government because there are many instances in which labs and research 
institutions produce new widgets but fail to initialize and act on a plan for the adoption 
and transfer of their new technology to private industry. The CRC would connect the 
REIT under development to the users who need it, facilitating communication and 
coordination between different offices within the federal government such as the Office 


of Research and Technology Applications and the National Science Foundation. 


Connecting the stakeholders in the CRC would provide the added benefit of 
exposing acquisition professionals (customers) and requirements generators to subject- 
matter experts. This approach would allow multiple experts to be questioned for a 
consensus-building effort instead of trusting a single expert to decide the fate of a 


complex program. 
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The CRC should be enabled to pull data from online financial resources as well as 
from government resources. Websites such as Google Finance 
(http://www.google.com/finance), Yahoo Finance (http//:;www.finance.yahoo.com), and 
Bloomberg (http://www.bloomberg.com) all have specific financial information that 


could be used to help establish the health and validity of a company. 


Historical information can sometimes be valuable in helping current and new 
programs through the acquisition process. Categorized programs completed or underway 
would be advertised to the user in order to show examples of failures and successes for 
the benefit of all the stakeholders. Examples of programs should also be categorized 
using a rating system to show how good or bad the acquisition was from the perspective 
of the user and the government. It could also be helpful to break down each acquisition 
into the components of the process in order to show the quality of localized events, such 
as “good” in IA but “bad” with interoperability. These assessments are subjective, but if 


they helped all parties reach a common ground, then their inclusion would be beneficial. 


The CRC is a new system designed to decrease the time it takes for REIT to go 
through the Integrated Defense Acquisition, Technology, and Logistics Life Cycle 
Management System. The way this is accomplished is through incentivizing stakeholder 
involvement, structured information sharing, and bridging technologies. The CRC aims 
to become the portal application that leverages the rest of the acquisition resources and 


technology throughout the DoD. 
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IV. BARRIERS TO ADOPTION 


The CRC will face technical, cultural, and policy barriers that might prevent its 
adoption by the DoD. Although these barriers exist, some of them are slowly being 
broken down by new technologies and new ideas. In this chapter, these technologies and 
the barriers they attempt to overcome are explored. The CRC, like all new technologies, 


will have to overcome these barriers to adoption. 


Four technologies that are already in use by some commands within the DoD will 
be discussed. The proposed technologies will directly improve the process of IT 
acquisition as well as the acquisition of all products and services involving REIT. The 
technologies are web portals, automated JCIDs, information assurance test ranges, and 
financial software. The purpose of discussing these technologies is to demonstrate that 
new concepts are not only possible but also currently in practice and already improving 
defense acquisition. The technologies described will provide improved information and 


knowledge to the CRC. 


A. TECHNOLOGICAL BARRIERS 
1. Portals and Adoption 


Commands should utilize web portal technology, such as Microsoft SharePoint, 
instead of routing hard-copy documents or attempting to manage document changes 
through e-mail. Routing, editing, and approving documents involved in the acquisition 
process can be accomplished more efficiently through the use of digitized documents on 
a web portal or similar technology. One important requirement of web portals is the 
security and authentication of the documents and users. Secure systems, such as the 


public key infrastructure (PKI), and encrypted systems used by the DoD are a necessity. 


Portals offer e-mail or other notification (e.g., text messaging) of document status 
changes to stakeholders in order to speed the acquisition process. Changes made to a file 
are instantaneously updated and tracked for all others to see. Another important feature 


of web portal technology is the ability to put time constraints on documents, forcing users 
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to edit and approve them before a deadline. Document version control is also a key 
aspect of web portals, especially when working with large groups of people. It is difficult 
to maintain a master version of a document when everyone is coordinating changes 
through e-mail. The ability of web portals to maintain a single version online with 


traceability of edits is important to prevent version duplicity. 


To take version control and web portals one step forward, a new technology 
called Google Wave allows multiple users to edit files simultaneously, negating the 
condition in software that normally occurs when two processes of execution depend on a 
shared state. Using Google Wave also allows anyone to start at the beginning of the 


changes made to a document and walk through them in linear fashion (Google, 2010). 


If a command requires printed paper to route documents for editing, validation, 
and approval, then valuable time is wasted in the acquisition process. The CRC and other 
technologies such as portals should be incorporated into policies and procedures in order 
to expedite all processing of administrative documents required for the acquisition of 


REIT and, in general, all products and services. 


2. Automated JCIDS or Semantically Informed Dynamic Engineering of 
Capabilities and Requirements 


Automated JCIDS is a_ software effort under development through 
MARCORSYSCOM’s Intelligence, Surveillance, and Reconnaissance Enterprise to 
demonstrate an effective capacity to automate the DoD JCIDS system. The JCIDS 
defines acquisition requirements and determines evaluation criteria for DoD programs, 
and it is a subpart of the Integrated Defense Acquisition, Technology, and Logistics Life 
Cycle Management System. The current JCIDS is complex and requires individual DoD 
organizations to produce and maintain capability development documents and initial 
capability documents for every program. These documents do not show common 
relationships between programs. Automated JCIDS is also referred to in the commercial 
industry as Semantically Informed Dynamic Engineering of Capabilities and 
Requirements Automated (SIDECAR) (Lenat & Rode, n.d.). The four main components 
of Automated JCIDS are as follows: 
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e A front-end template. This template follows a model similar to TurboTax 
by providing a user-friendly interface and help features. The system 
would take input on a new REIT’s requirements, constraints, and measures 
of performance. 


e A back-end database. This database can be searched and cross-referenced. 
Automated JCIDS takes user input and compares it with the information it 
knows to create necessary documents such as the capabilities development 
document. The system continues to ask the user questions in order to 
complete all of the documents the system finds related to the program. 


e Back-end models and algorithms. “Back-end models and algorithms that 
cross-reference and transform the various views in the inventory to create 
on-demand snapshots of the current state of alternatives and/or 
compliance” (Lenat & Rode, n.d.). 


° Multiple file formats. In order to meet DoD requirements, Automated 
JCIDS generates all of the required documents in desired formats. 


The Automated JCIDS takes the system features to be acquired as an input and 
guides the user through a step-by-step graphical user interface (GUI) in order to complete 
the documents required for the DoD JCIDS in accordance with rules and regulations. 
The system adds documents and asks additional questions based on the input from the 
user and back-end rules; as a result, the user is not required to remember all of the 
documents and rules needed, or be afraid of forgetting one. The added benefit to this 
system is its efficiency and accuracy in filling out forms while maintaining focus on 
content. Even when programmed correctly, software applications can make mistakes— 
but not as many as humans can make. The entire process is guided and is, therefore, 
designed for novice- and expert-level acquisition professionals. The expert users of the 
system have the option to see the original acquisition documents and directly edit them 


instead of using the GUI. 


The requirement of an individual to know all of the documents in the JCIDS 
Integrated Defense Acquisition, Technology, and Logistics Life Cycle Management 
System is a daunting task. To add further complexity, the documents overlap each other 
in the content of the information required. This redundancy wastes users’ time because 


they are required to fill in the same information multiple times throughout the process. 
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The Automated JCIDS system will identify these areas, request information one time, and 


fill in all necessary instances in which this information is required. 


Overall, the Automated JCIDS software will be a benefit to the Integrated 
Defense Acquisition, Technology, and Logistics Life Cycle Management System because 
it is efficient and cuts down on the time necessary to complete all of the paperwork 
required by the current system. Also, Automated JCIDS simplifies an acquisition 
professional’s job because it does not require the individual to remember all of the DoD 


statutory and regulatory policies and directives. 


3. Rapid IA Testing and Accreditation 


In a perfect world, REIT software and hardware could be tested on an operational 
network to verify IA certification, interoperability accreditation, and functional success. 
Today, technology exists for organizations at the local and enterprise levels to directly 
replicate their operational networks at a lower cost than building two duplicate networks. 
Using VMware, servers, and packet and pipe replication, enterprises can directly mirror 
their operational network down to all the programs running on it by using the same 


Internet Protocol scheme and using an IA test range. 


A DAA-approved IA test range could be used to quickly certify and accredit new 
REIT systems for IA and interoperability. The IA test range would be faster than normal 
because it would allow private industry to work on an operation-like network from the 
beginning to the end of a product’s development, making it so that the industry would not 


have to wait until demonstration times to see if the product would fail. 


The use of the test range would give acquisition professionals a more accurate 
picture of how the new REIT will function on the operational network without impacting 
the operational network with an outage, security risk, or added latency. The IA and 
interoperability organizations would benefit because the systems produced would be 
more likely to meet all the required standards and would have been tested thoroughly 


instead of just at baseline instances in time. 
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The IA test range concept is currently being used in the DoD by some 
organizations and is under development for the Marine Corps by MARCORSYSCOM. 
The relatively low cost of acquiring this technology makes it a viable solution to help 
expedite IA and interoperability certification and accreditation. Under the current 
process, if all the proper procedures are followed, then IA certification alone takes a 
minimum of a year and a half. A well-executed IA test range could accomplish the IA 


certification in months instead of years. 


4. Rapid Procurement Vehicles 


There are many different software efforts underway as well as in use across the 
DoD that create Quicken-like financial software features for the DoD according to how it 
budgets and executes spending within the FAR and the DFARS. The problem associated 
with the multiple programs is the lack of standards for sharing information between the 
distinct software solutions. If the software is proprietary and if each organization in the 
DoD uses a different one, then it is obvious how difficult it would be to get an accurate 
picture on a macro level. Additionally, if Quicken (or something like it) is not used, then 
the default alternate within the DoD is a massive Excel spreadsheet or some other 
proprietary, DoD-specific software. The DoD will only be able to execute its budget 
efficiently if there is an enterprise-level directive that mandates the use of the most 


capable interoperable software across the DoD. 


Furthermore, transparency within organizational chains of command is necessary 
to fully execute the budget. If a command is able to better track its budget, then it will 
have earlier insight into programs that are not performing and that could possibly fail in 
the future. Additionally, at an enterprise level, a senior command organization would 
have instant, up-to-date access to its subordinate’s budget in order to verify budget 
appropriations and to move money, if necessary, due to failing programs or new 
requirements. To compare this to banking software used in the home such as Quicken or 
to the online variant called Mint.com (http://www.mint.com), it would be useful to tie 
monetary transactions in and out of the treasury account to automatically update the 


QuickenGov software. 
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One simple proposal is to hire Intuit, the maker of Quicken, to produce software 
for the DoD and for the federal government. Quicken is arguably the commercial 
company with the most talent in financial software, now that Microsoft has cancelled its 
Microsoft Money software. After the software is developed, it could be integrated in the 
policies and procedures of the DoD. The end state of this integration would be a full, 


detailed budget report for Congress at the push of a button. 


5. Classification 


Manually classifying all current, new, and old DoD programs by capabilities and 
by topic and subtopics would be an overwhelming task. Therefore, an automated 
classification approach should be used. Through classification of old documents, the 


CRC would leverage the legacy systems in existence. 


The best current technology in automated classification is Statistical Machine 
Learning (SML; http://sml.nicta.com.au). The benefit to using SML is the extra steps it 
would allow a system to take to improve the accuracy of its classification and searching 
of acquisition documents. Document classification is easier in the case of acquisitions 
because the forms are more structured. In the following subsections, some example 


approaches for improving the accuracy of classification and searching are presented. 


a. Validated Documents 


The best approach to increasing SML accuracy is to provide the CRC with 
validated documents from which to learn. Validated documents are those that have been 
approved by acquisition professionals in content and format. Additionally, the DoD 
acquisition professionals who are most experienced should validate the best 
requirements, acquisition, and budget documents currently available by category and use 
them to start the learning process of SML. It is better to use a few validated documents 


than to use multiple documents that have been incorrectly completed. 
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b. Online Resources 


The CRC could add a large amount of information to its knowledge base 
from other online resources through its push-pull capability and from SML. As data is 
pulled into the CRC, it could be put through the SML filter to add information and raw 
data to the CRC knowledge base; it would not save all information, only the metadata and 


information needed for the CRC to know where to go when information is required. 


C. Human Involvement 


No SML system is perfect. In order to provide more accurate results, 
humans should be involved in randomly looking over the classification done using the 
SML. In addition to human verification, it would be important to allow all stakeholders 
to provide feedback to the system to make it more accurate. Two examples of the use of 
this method in private industry are Pandora Internet Radio (http://www.pandora.com) and 
Amazon.com (http://www.amazon.com). Both companies provide feedback mechanisms 
to make their applications stronger in providing better music results or a better shopping 
experience, respectively. Pandora offers a simple “thumbs up” or “thumbs down” 
feedback system, which allows its algorithms to learn whether the song suggested by the 
system matches what the user likes or originally asked for. The Amazon.com feedback 
system allows a user to rate products through a star system and text input. This 
information is then associated with the user’s account and run through the system’s 
algorithms, which then make suggestions about other products the user might like to 
purchase. These two examples demonstrate how both the enterprise system and the user 
benefit from feedback systems. The CRC should employ the concept of a feedback 


system in order to maintain search accuracy. 


d. Additional Feedback 


All systems that interact with people should learn from their users’ 
actions. A powerful feedback input to the CRC would be from the end user, or the 


warfighter. The warfighter would provide input on actual systems that were fielded or 
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under development. This input would give direct feedback to industry for product 
improvement and would also tell the acquisition professionals where to focus their 


spending. 


Feedback from the warfighter would be extremely important, but feedback 
from more than just the warfighter would be necessary in order to make a better CRC. 
The stakeholders should also be able to rate each other’s products, processes, and 
abilities. The companies that receive justified negative feedback should quickly be 
identified to the acquisition professionals and, in theory, lose business. A simple star 
rating with the option of adding amplifying text could be used to rank many aspects of 
the CRC. Amazon.com (http://www.amazon.com) is an example of a company that is an 


industry expert in this field. 


6. Technology Barrier Overview 


One policy required throughout all of the technologies listed in the previous 
subsection is the need to authenticate and validate who is on the CRC and who is making 
changes to it. Therefore, in addition to the technologies listed, it is important to 


incorporate the DoD CAC procedures using PKI. 


Again, technologies do not provide all of the answers for fixing the Integrated 
Defense Acquisition, Technology, and Logistics Life Cycle Management System. 
However, they do provide solutions to solve some of the problems within the system. 
The technologies listed in this chapter have all been developed for use commercially or 
for the federal government specifically and have shown success in their results. The DoD 


should adopt and invest in as many of these successes as possible. 


Outside of the technology barriers the CRC will face in its adoption, there are 
additional cultural barriers that will pose more of a challenge to its adoption. Human 
behavior is a difficult field of study because there are many intangible aspects. The CRC 
will face a DoD culture steeped in tradition and a stereotypical lack of innovative 


thinking. 
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B. CULTURAL BARRIERS 


Across the DoD there are many different cultures involved in the acquisition of 
REIT. In this author’s opinion, the cultural barriers to adoption involve the emotions of 
individuals, power struggles, and self-importance. The CRC and other technologies 
discussed in this chapter are technologically possible or already in use by consumers 
today. However, just because the technologies are possible does not mean that the 
cultural barriers they will face for entry into the DoD will be easy. Longstanding cultural 
attitudes and beliefs within the DoD, such as group think, make it difficult for individuals 
to embrace new ideas and methods for solving problems (Hewson, 2005). The defense 
acquisition culture has increasingly been tied down by bureaucratic requirements, self- 


imposed and external, that have led the culture to become one with the status quo. 


Cultural barriers will need to be broken in order for acquisition professionals to 
embrace the new concept of the CRC and the benefits it will bring to defense acquisition. 
The CRC’s initial success will require funding, research, policy changes, and a product 
demonstration. In this author’s opinion, these components, along with the CRC concept, 


will lead to a successful project start. 
1, Eighty Percent Versus One Hundred Percent Mentality 


The nature of the work the DoD is involved in has created a culture of zero failure 
(100% solution) and perfection with regard to the requirements set for systems, services, 
and equipment. This cultural norm is justified in many cases; however, it cannot be 
justified in all cases of REIT. This mentality is a barrier to the CRC and to acquiring 
REIT because it does not allow for evolutionary development, which is based on the 
principle of developing solutions through improvements iteratively (80% solution), 
possibly never reaching a 100% solution. Most people look at zero failure in the wrong 
way: failure is either optimal or epic. An epic failure is one that wastes large sums of 
money and provides no feedback to the system. An optimal failure is one that does not 


waste a lot of money and provides constructive feedback to the system. Optimal failure 
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is obviously desired. However, failure itself is a tough concept for most people, 
especially within the DoD, to accept. The CRC would show the benefits of both the 80% 


and 100% solutions by providing in-depth background information and analyses. 
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Vv. EXECUTION 


In this chapter, some steps that could help Collective Acquisition get traction 
within the DoD or federal government are described. One of the early keys will be 
finding both civilian and military champions of the process who can effectively market it. 
A prototype CRC would help in this regard, but without major funding up front to 
develop a nontrivial prototype, marketing could prove difficult. As a result, it is essential 


that proponents of the idea secure some initial funding for it. 


It will be necessary at the Senior Executive Service (SES) to have a proponent 
who controls funding and can influence policy. For this reason, it will be necessary to 
have a three- or four-star flag officer on the Joint Staff and one of the Under Secretaries 
of Defense who support the CRC. This senior top cover will be necessary because such 
leaders can override the cultural barriers the CRC will face as a new concept that 
challenges the normal way of doing business. Lower-level civilian and military 
operational champions will be necessary because they will fully understand all of the 
complexities of the CRC and will be able to explain them in a nontechnical way. It will 
be important to have as many senior and junior military and civilian operational 


champions from the original stakeholder list as possible. Among them are the following: 


e Requirements generators, 

e Private industry, 

e Government research labs and institutions, 
e Acquisition professionals, 

e Budget professionals, 

e IA organizations and policy-makers, and 

e Interoperability organizations. 


The more stakeholder involvement, the easier it will be to justify the CRC. It is 
also important to note that voluntary involvement in the project will provide an important 
foundation of information to the CRC. If a stakeholder cannot be convinced to 


voluntarily contribute to the CRC, then this would likely demonstrate to others a lack of 
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confidence in the system, resulting in the failure of the program itself. The CRC could be 
viewed as a threat to jobs and the status quo; therefore, the lower-level champions will be 
essential for explaining the CRC in nonthreatening terms to those who feel the system 
threatens their jobs. This will be necessary in order to gain their support and demonstrate 


the benefits of the CRC. 


A. PROOF OF CONCEPT 


The initial cultural barriers to entry that the CRC will face can be mitigated 
through the use of the operational champions. However, this is only a temporary solution 
and will not provide all the necessary components nor funding to the CRC. In order for 
the CRC to reach its full potential, it will need to be championed at the federal level and 
at the commercial-industry level, both of which provide products and services to the 
DoD. In an ideal situation, the initial operational champions will have provided enough 
research, funding, and top cover for a significant prototype to be built. The CRC 
prototype, in combination with the senior operational champions, is necessary to 


convince other noninnovators of its necessity and positive evolutionary impact. 


To succeed, it will be necessary for Congress to appropriate adequate funding to 
the CRC, but, more important, Congress will need to require by law that industry and the 
federal government provide the necessary input to the CRC. This requirement will be 
necessary because the stakeholders will not all voluntarily participate in the project. The 
inclusion of all of the initial stakeholders is important because the CRC will not reach its 


full potential without them. 


Congress will not be hard to convince of the benefits as long as a CRC proof of 
concept can be demonstrated to streamline the efficiency of defense acquisition, cut out 
waste, save money, and provide incentives to small and large businesses for jobs to their 
constituents. The perfect CRC demonstration would include the acquisition scenario 
listed in Chapter I and a background visualization of the cross-domain resources the CRC 
was able to bridge in order to come to its recommendations. This would not be a new 


concept for Congress since they have made laws in the past requiring the DoD and 
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industry to comply with new concepts (e.g., industry registration in a contractor 
database). Congress carries a “big stick” when it comes to industry involvement because 
they can withhold income from companies that do not comply with their mandates. 
Ideally, every stakeholder will voluntarily comply with the CRC because of the 
incentives and evolutionary benefits it will provide. Congress will be helpful in 
persuading the members of industry and the federal government who do not want to lose 
their stovepipes of profit and power. Another simple example would be for the CRC to 
show waste in the defense acquisition system by identifying two organizations (e.g., the 
Navy and the Marines) that are about to purchase nearly the exact same product or 
service. The CRC would proactively show the waste and provide more information about 
the two companies from which the Services intend to make a purchase. In the same 
manner, the CRC could expose corrupt companies that are trying to double dip and sell 


the same product to the government under two different contracts. 


It is important to demonstrate the initial capability of the CRC to Congress and 
others in order to gain constructive feedback and prove that money is being spent wisely. 
The evolutionary way in which the CRC will be developed should also produce 
demonstrations at the end of each iteration. By demonstrating continued success and 


management of expectations, the DoD will gain more support for the CRC. 


B. INDUSTRY ACCEPTANCE 


Federal government stakeholders are the most likely to participate because they 
are governed by federal law. Private industry is a different story. In this author’s 
opinion, although private industry is obligated to obey the laws of Congress, they have 
more money and lawyers to fight new concepts when faced with competition. The 
incentives discussed in Chapter III will ideally bring private industry to understand the 
CRC opportunities because they will feel the benefit from the CRC. In order to minimize 
noncompliance and grow rapid support within industry, it will be important to design the 
CRC to be as open, secure, and user-friendly as possible. The CRC human computer 


interface should be thoroughly tested. The easier and more automated the system is, the 
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less likely there will be resistance from the stakeholders. In the end, it is all about 
making the CRC a positive experience by making it nearly effortless for stakeholders to 
participate in the CRC interface. 


C; OVERCOMING DEMOTIVATION 


People are the most important asset of the DoD, and they are crucial in 
performing the tasks required by the defense acquisition system for new projects. In this 
author’s opinion, people can be further grouped into categories of motivators or 
demotivators. A motivator will always maintain an open mind with regard to new 
concepts, work hard at what they do, and, in general, see the big picture when it comes to 
acquisitions. Unfortunately, the DoD is also full of demotivators. Demotivators could be 
good at what they do, but, in general, “no” is their first answer to anything outside the 
norm or to anything that could possibly put them out of a job or require them to do work 
they are not used to doing. The CRC will face the demotivators at the peak of their 
demotivation because the CRC will threaten the normal way of business and could be 
seen as an attempt to automate human involvement in defense acquisition. For this 
reason, it will be crucial to identify the demotivators as early as possible and to determine 
the best way to work around or replace them. These individuals should not immediately 
be dismissed because they possess core knowledge about who can get things done when 
needed. The CRC will aim to help these individuals be more efficient and streamline 
their work, potentially turning them into motivators. The CRC will provide a 
collaborative environment full of motivators and other experts that will allow users to 
easily bypass the demotivators. The other important combatants in the fight against 
demotivators are the senior operational champions. The benefit of being a senior leader 
in a vertical organization is having the ability to defeat demotivators through orders, 
reasoning, or removal from projects. These senior leaders will be necessary in order to 
convince others that the CRC is an important evolutionary step in the future of 


acquisitions. 
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D. FOCUS ON EMOTION 


In this author’s opinion, the one commonality across the federal government with 
regard to defense acquisition is the deep feeling (i.e., frustration) that work could be done 
more efficiently and could produce better results. This feeling, evoked when anyone 
within the DoD is asked about the acquisition system, could be used as a strong enabler 
for the CRC. The feeling of frustration stirred by the acquisition system can partly be 
mitigated with the use of technology. The criterion for mitigation is adoption of the 
technology into the normal operations of the acquisition system and the simplicity of that 
technology. In this author’s opinion, people are most likely to try something new when 


they are extremely disappointed with the current system. 


As discussed in Chapter IV, feedback is an important aspect of the acquisition 
process because it gives individuals a sense of importance and provides valuable 
information to the CRC. The feedback from seeing direct results based on an individual 
input is an important feature that the CRC will provide. The feedback within the CRC 
could make a contribution to a cause that an individual knows will help him or her save a 
life in the future, such as a recommendation for changing the design of a critical piece of 


communications equipment. 


E. OPERATIONAL COMMAND INVOLVEMENT 


The operational commander should be involved in the process for acquiring 
technology relevant to his or her mission. This involvement would provide a commander 
with the means of making the decision on the value of bringing in an early technology 
with the 80% solution, as long as he or she made the decision knowing the associated 
risks. Furthermore, commanders would provide direct feedback into the decision cycle, 
which would benefit future iterations of the REIT and provide feedback to the DoD about 
whether the 80% is a quality REIT or whether it does not meet the requirements. The 
CRC would stay involved throughout the entirety of this process and would provide the 


operational commander with extra resources (e.g., subject-matter experts). 
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F. ACCOMMODATING 


Initially, the CRC would not replace any systems; therefore, it would not threaten 
any powerful stovepipes existing in the federal government. If people are made to feel 
that their power base will gain importance rather than be threatened, then they will be 
more likely to support aspects of the CRC. An effort should be made to brand the CRC 
as a third-party application that would not take money or resources away from any 
program, but rather enhance what is already underway. In the future, if the online 
resources were found to be more efficient under the CRC umbrella, then the system 
would be made open enough to envelope them, but this decision would be made by future 


policy-makers. 


G. DEFENSE ACQUISITION UNIVERSITY 


In addition to showing a prototype CRC and explaining the value the CRC will 
bring, an important emphasis should be made with regard to the Joint Forces going 
through DAU training and certification. Because students are impressionable, they 
represent the easiest way to spread information when they enter the workforce. Students 
would easily adopt the CRC as a new concept and would continue to provide momentum 


for the CRC project. 
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VI. SUMMARY AND FUTURE WORK 


A. SUMMARY 


The DoD is burdened by an Integrated Defense Acquisition, Technology, and 
Logistics Life Cycle Management System that is designed to acquire large systems, such 
as ships, and that takes years to complete. Information technology evolves at a rapid 
pace because it is driven by industry. The DoD acquisition system is therefore at odds 
with industry development, at least with respect to information technology. The 
acquisition of information technology cannot follow the same path as a ship if the DoD 


wants the warfighter to have the most advanced technologies. 


The current acquisition process is burdened with many obstacles. It is an artifact 
of an industrial—military alliance that has evolved over many years. As such, it is riddled 
with special provisions, regulations, directives, best business practices, etc., that have 
become a veritable mine field to navigate. Other obstacles include a DoD culture and 
larger political environment that together add multiple layers of bureaucracy and 
uncertainty to the process. It is unrealistic to expect a clean slate in order to begin 
designing a totally new process. Realistically, as much current practice as possible has to 
be incorporated in order to make any real progress. To understand what incorporation 
means, current practice needs to be understood—not at the level of published procedures, 
but rather at the level of the trenches or frontlines where real acquisition decisions are 
made today. To that end, the author embedded himself in three system commands over a 
period of 12 months to observe operations. The author observed several areas in which 
improvements are needed, among them are policy, laws, education, and culture. This 
thesis recommended changes that should occur in the acquisition process for the types of 


technology that evolve very quickly. 


One of the changes that needs to occur is the sharing of information about a 
variety of things. The acquisition of technology is about much more than the technology 
alone. Each stage of the acquisition process, even for technologies that are never 


ultimately adopted, offers some information that needs to be cataloged in a way that 
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makes it useful to others. This thesis proposed a clearinghouse for this purpose, called 
the Capabilities and Requirements Clearinghouse (CRC). The CRC would decrease the 
amount of time required to get information technology to the warfighter. It would do so 
by relating existing resources, automatically crawling through data, and providing a 
single source of information for all aspects of acquisition. The DoD loses some of its 
ability to acquire information technology because economies of scale are not maximized 
through the relationship of program information. The lack of relationships between 
online resources and databases causes many steps to be repeated. Going forward, it will 
be unacceptable to maintain stovepipes of web resources. Instead, the online resources 


will need to be integrated, and the CRC provides a framework for accomplishing this. 


The changes that need to occur are not limited to information sharing. Although 
that is a central component, other barriers must be overcome. These barriers are in the 
following areas: 

e Certification and accreditation, 

e Budgeting flexibility, 

e Testing and validation, and 

e Cultural hurdles. 

Currently, certification and accreditation involve many parties, such as the NIST, 
the NSA, a Service’s DAA, and so on. The process produces artifacts such as FIPS 
certificates and test suites within which products are certified. These artifacts may be 
used in the certification of new products. For instance, a cryptographic module’s 
certificate may be reused to certify another product if that product uses the same module. 
How do we know which module was used? How do we know in which environment the 
module was tested? The answers to these questions would be available through the CRC, 


which would catalog information along many different axes. 


The DoD’s Planning, Programming, Budgeting, and Execution process is not 
transparent or flexible enough to accommodate the pace at which information technology 


evolves. In order to improve this, a Quicken-like software package is recommended. 
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The package should be mandated DoD-wide in order to share budget information across 
the Services and to provide greater visibility into budget issues. This way, budget 


problems will be revealed earlier. 


As far as testing and validation is concerned, relatively fewer changes seem to be 
needed. The reason is the JA test range already provides a configurable network test 
environment to facilitate testing. It appears that one of the major shortcomings of the 
range is its ability to interface with other data repositories like the CRC. For instance, 
knowing the exact configuration cataloged by a vendor would allow a DAA to more 
quickly compare products from different vendors because knowing the configuration 


would level the playing field. 


The cultural hurdles will be more difficult to overcome and will require decision- 
makers to improve the system by evaluating and merging current DoD acquisition rules. 
Removing duplicate rules and requirements that require extra work will be the fastest 
way to improve the acquisition system. In addition, the cultural belief that 80% 
perfection is a failure needs to be better explained with regard to information technology. 
An iterative process that produces only an 80% solution is often adequate. Some 


professionals find this difficult to accept and need to adapt. 
B. FUTURE WORK 


In order to execute the CRC, a significant amount of effort will be necessary to 
build, validate, and test the conceptual idea. Additionally, work will need to be done to 
relate the online resources and explore the technologies discussed in this thesis. The goal 
of future work should be to improve on the foundation presented in this thesis and 


produce a CRC prototype. 


The CRC will most importantly need both DoD and congressional champions in 
order to be successful. These champions should make efforts to rally for support of the 
CRC in their respective organizations and push for consolidation of resources. In 
addition, effort will be necessary to motivate others to review current and past policies, 


laws, and rules in order to simplify and streamline them. These will have a direct, 
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positive impact on the CRC. Within the DoD, the first champion should be the Defense 
Advanced Research Projects Agency (DARPA) and the Office of the Under Secretary of 
Defense for Acquisition, Technology, and Logistics. These organizations have the 
money, resources, and expertise to nurture the CRC. It is key to get initial validation, or 
a toehold, by an agency actually acquiring information technology. An example of such 


an agency is the Defense Information Systems Agency (DISA). 


Current federal laws and DoD policy documents dictate the rules for who, what, 
when, where, why, and how an individual, company, or organization can share 
information within and outside the DoD and federal government. The number of 
documents, policies, laws, rules, etc., is far too great for any one person to master. These 
rules will need to be codified and represented within the CRC so that no violations occur. 
Therefore, research will need to be done to create a database of all rules and their 


dependencies and to represent them in the CRC. 


The list of online resources in Appendix D is a very brief list of what is available 
to the DoD and federal acquisition communities. Research is needed to identify all of the 
additional websites and databases that will need to be identified in order to relate or 
consolidate resources. The overlap of resources is a key area of study that needs 
attention. Additionally, the information and data contained in the identified resources 
will need to be organized and plugged into the CRC so that it may serve as the front end 
to these resources. Further research is required in the categorization of the information 


and data using SML, as discussed in this thesis. 


Further research is needed to identify how technologies such as the proposed 
QuickenGov and Automated JCIDS would relate to the CRC and other new resources 
identified. Specifically, research into technology and the level at which it is interoperable 


with the CRC will need to be identified. 


In Chapter V, the many issues that the CRC will face with regard to social science 
were discussed. Further research is needed to study how the CRC will impact the 
emotions of DoD personnel. Also, more research is required as to how human emotions 


by personnel in the DoD will impact and drive the CRC. 
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As much as possible, all aspects of the CRC should be kept at an unclassified 
level. However, if a higher classification of the CRC is needed, then it should be 
carefully engineered with the ability to cross enterprise domains in order to pull 
information. Research will be needed to determine how to set up this relationship 
between software programs on different domains as well as how to control multilevel 


access to information. 
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APPENDIX A. HARDWARE AND SOFTWARE TECHNOLOGY 
READINESS LEVELS TABLE 


Technology Readiness Levels (TRLs) are metrics used by the DoD to determine 
the maturity of rapidly evolving technologies. This maturity can then help the DoD 
determine the risk for adoption of the technology. Furthermore, TRLs are a way for 
acquisition professionals to estimate how much time it will take for a technology to reach 
completion or production. See Table | in this appendix for a full list of the definitions of 
TRLs as defined by the DoD Technology Readiness Assessment (TRA) Deskbook 
(2009). 
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Table 1. 


Lowest level of technology readiness. Scientific research begins to 
be translated into applied research and development (R&D). Exam- 
ples might include paper studies of a technology's basic properties. 


Published research that identifies the principles that underlie this 
technology. References to who, where, when. 





Invention begins. Once basic principles are observed, practical 
applications can be invented. Applications are speculative, and 
there may be no proof or detailed analysis to support the assump- 
tions. Examples are limited to analytic studies. 


Publications or other references that outline the application being 
considered and that provide analysis to support the concept. 





Active R&D is initiated. This includes analytical studies and labora- 
tory studies to physically validate the analytical predictions of sepa- 
rate elements of the technology. Examples include components that 
are not yet integrated or representative. 


Results of laboratory tests performed to measure parameters of 
interest and comparison to analytical predictions for critical subsys- 
tems. References to who, where, and when these tests and com- 
parisons were performed. 





Basic technological components are integrated to establish that 
they will work together. This is relatively “low fidelity” compared with 
the eventual system. Examples include integration of “ad hoc” 
hardware in the laboratory. 


‘System concepts that have been considered and results from 
testing laboratory-scale breadboard(s). References to who did this 
work and when. Provide an estimate of how breadboard hardware 
and test results differ from the expected system goals. 





Fidelity of breadboard technology increases significantly. The basic 
technological components are integrated with reasonably realistic 
supporting elements so they can be tested in a simulated environ- 
ment. Examples include “high-fidelity” laboratory integration of 
components. 


Results from testing a laboratory breadboard system are integrated 
with other supporting elements in a simulated operational environ- 
ment. How does the “relevant environment" differ from the expected 
operational environment? How do the test results compare with 
expectations? What problems, if any, were encountered? Was the 
breadboard system refined to more nearly match the expected sys- 
tem goals? 





Representative model or prototype system, which is well beyond 
that of TRL 5. is tested in a relevant environment. Represents a 
major step up in a technology's demonstrated readiness. Examples 
include testing a prototype in a high-fidelity laboratory environment 
or in a simulated operational environment. 


Results from laboratory testing of a prototype system that is near 
the desired configuration in terms of performance, weight, and vol- 
ume. How did the test environment differ from the operational envi- 
ronment? Who performed the tests? How did the test compare with 
expectations? What problems, if any, were encountered? What 
are/were the plans, options, or actions to resolve problems before 
moving to the next level? 





Prototype near or at planned operational system. Represents a 
major step up from TRL 6 by requiring demonstration of an actual 
system prototype in an operational environment (e-.g., in an aircraft, 
in a vehicle, or in space). 


Results from testing a prototype system in an operational environ- 
ment. Who performed the tests? How did the test compare with 
expectations? What problems, if any, were encountered? What 
are/were the plans, options, or actions to resolve problems before 
moving to the next level? 





Technology has been proven to work in its final form and under 
expected conditions. In almost all cases, this TRL represents the 
end of true system development. Examples include developmental 
test and evaluation (DT&E) of the system in its intended weapon 
system to determine if it meets design specifications. 


Results of testing the system in its final configuration under the 
expected range of environmental conditions in which it will be 
expected to operate. Assessment of whether it will meet its opera- 
tional requirements. What problems, if any, were encountered? 
What are/were the plans, options, or actions to resolve problems 
before finalizing the design? 





Actual application of the technology in its final form and under mis- 
sion conditions, such as those encountered in operational test and 
evaluation (OT&E). Examples include using the system under 
operational mission conditions. 


OT&E reports. 
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Definitions of Technology Readiness Levels 


| TRL Definition | —~——=—S~S~C~éescription SS SSS—=S@d ‘Supporting Information 


Lowest level of software technology readiness. A new software 
domain is being investigated by the basic research community. This 
level extends to the development of basic use, basic properties of 
software architecture, mathematical formulations, and general 
algorithms. 


Basic research activities, research articles, peer-reviewed white 
papers, point papers, early lab model of basic concept may be 
useful for substantiating the TRL. 





Once basic principles are observed, practical applications can be 
invented. Applications are speculative, and there may be no proof 
or detailed analysis to support the assumptions. Examples are 
limited to analytic studies using synthetic data. 


Applied research activities, analytic studies, small code units, and 
papers comparing competing technologies. 





Active R&D is initiated. The level at which scientific feasibility is 
demonstrated through analytical and laboratory studies. This level 
extends to the development of limited functionality environments to 
validate critical properties and analytical predictions using non-inte- 
grated software components and partially representative data. 


Algorithms run on a surrogate processor in a laboratory environ- 
ment, instrumented components operating in a laboratory environ- 
ment, laboratory results showing validation of critical properties. 





Basic software components are integrated to establish that they will 
work together. They are relatively primitive with regard to efficiency 
and robustness compared with the eventual system. Architecture 
development initiated to include interoperability, reliability, maintain- 
ability, extensil ', scalability, and security issues. Emulation with 
current/legacy elements as appropriate. Prototypes developed to 
demonstrate different aspects of eventual system. 


Advanced technology development, stand-alone prototype solving a 
synthetic full-scale problem, or standalone prototype processing 
fully representative data sets. 





Level at which software technology is ready to start integration with 
existing systems. The prototype implementations conform to target 
environmentinterfaces. Experiments with realistic problems. Simu- 
lated interfaces to existing systems. System software architecture 
established. Algorithms run on a processor(s) with characteristics 
expected in the operational environment. 


System architecture diagram around technology element with criti- 
cal performance requirements defined. Processor selection analy- 
sis, Simulation/Stimulation (Sim/Stim) Laboratory buildup plan. 
Software placed under configuration management. Commercial-of- 
the-shelf/government-off-the-shelf (COTS/GOTS) components in 
the system software architecture are identified. 





Level at which the engineering feasibility of a software technology is 
demonstrated. This level extends to laboratory prototype imple- 
mentations on full-scale realistic problems in which the software 
technology is partially integrated with existing hardware/software 
systems. 


Results from laboratory testing of a prototype package that is near 
the desired configuration in terms of performance, including physi- 
cal, logical, data, and security interfaces. Comparisons between 
tested environment and operational environment analytically under- 
stood. Analysis and test measurements quantifying contribution to 
system-wide requirements such as throughput, scalability, and reli- 
ability. Analysis of human-computer (user environment) begun. 





Level at which the program feasibility of a software technology is 
demonstrated. This level extends to operational environment proto- 
type implementations, where critical technical risk functionality is 
available for demonstration and a test in which the software tech- 
nology is well integrated with operational hardware/software sys- 
tems. 


Critical technological properties are measured against requirements 
in an operational environment. 





Level at which a software technology is fully integrated with opera- 
tional hardware and software systems. Software development 
documentation is complete. All functionality tested in simulated and 
operational scenarios. 


Published documentation and product technology refresh build 
schedule. Software resource reserve measured and tracked. 





Level at which a software technology is readily repeatable and 
reusable. The software based on the technology is fully integrated 
with operational hardware/software systems. All software docu- 
mentation verified. Successful operational experience. Sustaining 
software engineering support in place. Actual system. 





Production configuration management reports. Technology inte- 
grated into a reuse “wizard.” 





APPENDIX B. ACQUISTION OVERVIEW CHART 


The Integrated Defense Acquisition, Technology, and Logistics Life Cycle 
Management System chart in Figure 3 shows complexity. The chart can be found on the 


Defense Acquisition University’s website (http://www.dau.mil). 


49 





~~ Integrated Defense Acquisition, Technology, and Logistics Life Cycle Management System Fa 

















Figure 3. Integrated Defense Acquisition, Technology, and Logistics Life Cycle Management System (from http://www.dau.mil) 


50 


APPENDIX C. OPERATIONAL DEFICIENCY REPORT 


The template below is a generic example of what an operational deficiency report 
could look like. 

From: 

To: 

Subj: OPERATIONAL DEFICIENCY REPORT (ODR) 








1. Operational Requirement. Provide a brief description and summary 
addressing the operational requirement (who, what, where, when, why, how). 


a. Capability Required. Describe what is required in operational terms. 
If possible, identify the system, equipment, component, procedure, 
etc., that will provide a solution to the operational deficiency. 


b. Operational Deficiency. Describe the existing operational deficiency 
(capability gap). Explain why existing systems or procedures fail to 
provide the results or effects required. 


2. Concept of Operations. Outline the concept of operations (how would the 
required kit/system/platform, etc.) to be employed to overcome the 
operational deficiency. 


3. Additional Supportive Information. Provide additional information, as 
available, that further clarifies/supports the requirement. For example, 


Will this be a new item, or will it replace an existing item/system? 
b. Give the potential technology or vendor. 


c. List other units/Services/organizations that have a potential solution or 
similar requirement. 


4. ODR Sponsor Point of Contact. 


Signature. 
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APPENDIX D. ONLINE ACQUISITION RESOURCES 


The following list describes some of the current online acquisition resources that 
should be consolidated or related to improve the Integrated Defense Acquisitions, 


Technology, and Logistics Life Cycle Management System. 


A. DOD TECHIPEDIA 


DoD Techipedia is a wiki sponsored by the Defense Technical Information Center 
(DTIC) that is designed to increase communication and collaboration among DoD 
scientists, engineers, program managers, and operational warfighters. This tool enables 
DoD personnel to collaborate on technological solutions, reduce costs, add capability, 


and avoid duplication through a common wiki (Department of Defense [DoD], n.d.c). 


The CRC would gain an immense knowledge base from the DTIC because it is 
the largest central resource depository for DoD- and government-funded scientific, 
technical, engineering, and business information. Specifically, DoD Techipedia has 
created relationships between stakeholders (requirements generators, the Federal 
Laboratory Consortium, acquisition professionals, IA, and interoperability organizations) 
who have common interests within the DoD in order to leverage the collective power of 
the individuals in the federal system (DoD, n.d.c). This is one of the criteria that the 
CRC should provide. In addition to the service provided by DoD Techipedia, the CRC 
would add the remaining stakeholders (private industry and budget professionals) as 
collaborators who would contribute and find information based on their common 


interests. 


B. DOD IT STANDARDS 


DoD IT Standards was created by the Office of the Secretary of Defense 
(Networks & Information Integration) DoD Chief Information Officer, who is 
responsible for setting policy and providing oversight of information processes, systems, 
and technologies (http://cio-nii.defense.gov/). DoD IT Standards focuses on three major 


activities: policy development, program oversight, and acquisition support. The CRC 
a), 


would benefit from the DoD IT Standards by pulling standards information from one up- 
to-date source. The CRC could then use this information to advertise information to 
private industry. Furthermore, the CRC could compare the standards to standards 
advertized by private industry as an extra step of verification for industry compliance 
(Office of the Secretary of Defense for Networks & Information Integration, Chief 
Information Officer [OSD(NII/CIO)], n.d.). 


C. INFORMATION ASSURANCE SUPPORT ENVIRONMENT 


The Information Assurance Support Environment (IASE) provides a single 
location for everything related to [A C&A and interoperability. Similar to the relationship 
between the CRC and DoD IT Standards, the IASE would provide essential IA C&A and 
interoperability sources to the CRC. An important aspect of the [ASE is that it is fed by 
multiple supporting online resources such as the NIST Special Publications Computer 
Security Division (CSD), which is responsible for providing minimum standards and 
technology to protect information systems against threats. Furthermore, it hosts a 
growing repository of federal agency security practices, public and private security 


practices, and security configuration checklists for IT products (DoD, n.d.b). 


D. CONTRACTOR PERFORMANCE ASSESSMENT REPORTING SYSTEM 


A Contractor Performance Assessment Reporting System (CPAR) assesses a 
contractor’s performance and provides a record, including both positive and negative 
ratings, on a given contractor as dictated by the FAR (Defense Information Systems 
Agency [DISA], n.d.). CPARS is a web-enabled application that collects and manages 
the library of automated CPARs. Each assessment is based on objective facts and is 
supported by program and contract management data, such as cost performance reports, 
customer comments, quality reviews, technical interchange meetings, financial solvency 
assessments, construction and production management reviews, contractor operations 
reviews, functional performance evaluations, and earned contract incentives. The CRC 
would pull information from CPARS and relate that information to industry capabilities 


(past, current, and future). The CRC could use the CPAR data to provide amplifying 
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information to its query results for capabilities and could use the information to provide 
ratings for products and contractors. Because the FAR dictates that past performance 
information (PPI) be collected and used in source selection evaluations throughout the 
acquisition process, the CRC would show the relationships on a macro level in order to 
provide stakeholders with the right information so that they could make the correct 


acquisition decisions (DISA, n.d.). 


E. GENERAL SERVICES ADMINISTRATION, SOFTWARE MANAGED 
AND ACQUIRED ON THE RIGHT TERMS 


Software Managed and Acquired on the Right Terms (SmartBuy) is a federal 
procurement vehicle that provides faster licensed software and software-related services 
at considerable savings through established blanket purchase agreements (BPAs). The 
General Services Administration (GSA) offers the opportunity to view and select from an 
expanding list of COTS software. The CRC would pull information from SmartBuy to 
add to its knowledge base of products and their capabilities. As users or the system query 
the CRC, the SmartBuy data would provide an expedited existing material solution with a 
contracting vehicle. This is a great example of the CRC because it would match an 
existing capability with a current requirement. Furthermore, it would provide a quick 
means for acquisition because a contracting vehicle already exists for the DoD (General 


Service Administration [GSA], n.d.). 


F. CENTRAL CONTRACTOR REGISTRATION 


The Central Contractor Registration (CCR) fills the FAR requirement for 
contractors to register their companies in order to do business with the federal 
government. It collects, validates, stores, and disseminates data on all known contractors 
conducting business with the DoD (https://www.bpn.gov/ccr/default.aspx). The CRC 
would pull information from the CCR in order to build relationships between contractor 


names, numbers, and their products. 


a, 


G. CONTRACTOR COST AND DATA REPORTING 


Contractor Cost and Data Reporting (CCDR) is the authoritative source of 
information associated with the Cost and Software Data Reporting (CSDR) system. 
CSDRs are the primary means by which the DoD collects data on the costs that 
contractors incur while working on DoD programs. CSDRs are the DoD’s only 
systematic mechanism for capturing completed development and production contract 
costs, which provide more credible cost estimates for realistic budget estimates (DoD, 
n.d.a). The CRC would pull the CCDR information and relate the information to 
capabilities queried. This would provide amplifying information to stakeholders so that 


they could more accurately make decisions in acquisition programs and projects. 
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